Transaction Safe Nonblocking Data Structures

This brief announcement focuses on interoperability of software transactions with ad hoc nonblocking algorithms. Specifically, we modify arbitrary nonblocking operations so that (1) they can be used both inside and outside transactions, (2) external uses serialize with transactions, and (3) internal uses succeed if and only if the surrounding transaction commits. Interoperability enables seemless integration with legacy code, atomic composition of nonblocking operations, and the equivalent of hand-optimized, closed nested transactions. The key to transaction safety is to ensure that memory accesses of operations called from inside a transaction occur (or appear to occur) if, only if, and when the surrounding transaction commits. We do this by making writes manifestly speculative, with their fate tied to that of the transaction, and by logging reads for re-validation immediately before the transaction commits. (Because correct nonblocking code is designed to tolerate races, additional, intermediate validation is not required.) When called from outside a transaction, operations behave as they did in the original nonblocking code, except that they aggressively abort any transaction that stands in their way. Operations inside a transaction similarly abort transactional peers. They are unaware of nontransactional peers. We provide nonblocking objects with “transaction aware” versions of references and other basic primitive types such as integer, long, etc. These provide Get, Set, and CAS operations, which the programmer uses instead of conventional accesses. If called inside a transaction, Get logs the target location for later validation; Set and CAS speculatively modify the target location. Changes become permanent at transaction commit time. If called outside a transaction, all three operations “clean up” any encountered speculative updates, aborting conflicting transactions if necessary. Given correct nonblocking code, the changes required to create a transaction-safe version are mechanical. To make a type transaction-aware, we must be able to distinguish between real and speculative values. For some types (e.g., pointers in C) we may be able to claim an otherwise unused bit, or use features such as runtime type identification in strongly typed languages such as Java. For others we may use a sentinel value to trigger address-based lookup in a separate metadata table. With support for transaction aware primitives, we expect that construction of transaction safe versions of nonblocking algorithms would require little or no